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Introduction 


• NetworkSimulation: 

— Mathematical approximation of network performance 
— Discrete event based simulation of expected behavior 

• Network Emulation 

— High-fidelity network protocol models 

— Performed in realtime 

— Can run emulation in parallel with operational 
hardware 

• Benefits of Emulation: 

— System-in-the-loop emulation 

• Can test operational hardware / software in a real end-to- 
end network path 
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Introduction 


• Real-time Emulation 

— Can test non-ideal networking scenarios 

- Packet drops, excessive delay, etc 

— Observe how actual hardware / code reacts to 
these situations. 


Hardware in the Loop (HITL) Emulation 



4 


NASASCaN Program 


• Space Communication and Navigation (SCaN) Program 

• Encompasses NASA's three operational space communication networks: 

- Near Earth Network (NEN) 

- Space Network (SN) 

- Deep Space Network (DSN) 

• Three of SCaN Program Goals: 

- Develop a unified space communications and navigation network 
infrastructure capable of meeting both robotic and human exploration mission 
needs. 

- Assure data communication protocoIsforSpace Exploration missions are 
internationally interoperable. 

- Continue to meet its commitmentsto provide space communicationsand 
navigation services to existing and planned missions. 

• Unified networking infrastructure: 

- Requires extensive emulation and simulation testing 

- Verification that new protocols meet required standards and interoperate with 
legacy equipment. 
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SCENIC Emulation Lab 


• NASA GRC SCaN Compatibility Environmentfor Networks and 
Integrated Communications (SCENIC) Emulation Lab 

- Currently under development at NASA Glenn Research Center 

- Identify and address gaps that enable implementation of the NASA 
Integrated Network Architecture (INA) 

- Provide a SCaN system and network training environment for new 
Systems Engineers, Co-ops, and interns to practice on NASA SCaN 
equipment 

- Perform system analysis, design, development and performance 
evaluation tasks. 

- Evaluate Vendor provide software options in a relevant environment 
with mission characteristics. 

- Facilitates the validation and verification of the SCaN integrated 
network to minimize risk, ensure safety and enable overall operational 
success. 
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Focus of Research 


• Focus of this Emulation Research: 

- Emulation of Space Link Extension (SLE) Protocol 

• New implementation developed by Ingenicomm 

• Designed to support future high data-rate communication links 

• Up to 1.2-Gbpsfor Ka-Band communication links 

• Focus of presented tests: 

- Emulation of expected and worst-cast round-trip-time 
between SLE User and Provider 
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Space Link Extension 


• CCSDS Recommended Standard 

• Tunneling protocol for Layer-2 CCSDS Frames or binary data 

• Only used for ground network communications 

• Provides interface to underlying transport layer protocol 

- Typically utilizesTransport Control Protocol (TCP) 

- Transport Layer provides reliability and congestion control 


Application Layer 




Layer-2 Frames 


Layer-2 Frames 

SLE Fonward User 

SLE Return User 

SLE End-to-End Link ► 

SLE Forward Provider 

SLE Return Provider 

SLE ISP Protocol 


SLE ISP Protocol 

Transport Layer Protocol 

-•-TCP/UDP End-to-End Link-^ 

Transport Layer Protocol 

Network Layer Protocol 

Layer-3 Network [-► 

Network Layer Protocol 


Application Layer 


Layer-2 Frames 


Remote User Site 


Ground Network 


Ground Station 


Wireless 

Space 

link 


Spacecraft 


8 


SCENIC Emulation Lab 


• SCENIC Emulation Lab for SLE Emulation 

— Space Link Extension (SLE) Servers 

• SLE User- User Site 

• SLE Provider- Remote Ground Station 

- 10 Gbps Fiber network 

• Supports maximum desired rate of 1.2 Gbps 

• Isolation from NASA GRC Network 

- Wide Area Network emulation: 

• LinuxTrafficControl (TC) functionality 

- Network delay 

- Jitter 

- Packet drop rate 

• Emulate network characteristics in real-time 
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Baseline Network Results 


Initial emulation tests 

- Network connection through Ingenicomm CGS Software 

- Without SLE Encapsulation 

• Timestamp data tunneled directly over TCP/IP 

- Offered load: 1.2 Gbps 

• Maximum data rate for Single-Access Ka-Band communication link 

- Maximum RTT delay: 200 ms 

• Max expected delay for NISN 
CONUS network connection 

- Full 1.2Gbps sustained 
throughout test 
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SLE Testbed Configuration 


• Ground network emulation through Linux Servers 

• Emulate same round-trip-time (RTT) delay as 
baseline network configuration test. 

• Forward (F-CLTU) and Return (RAF) SLE Protocol tests 
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SLE Results 


SLE F-CLTU Protocol Throughput Results: 


SLE Forward CLTU Average Throughput (Mbps) 



SLE Results 


SLE Return All Frames Protocol Throughput Results 


Average Throughput for SLE Return All Frames (RAF) Service 



SLE Initial Results 


• Significant decrease in achievable throughput with 
increasing network delay. 

• Approximately 2. 1-2.5 Mbps throughput with full 
200 milliseconds network delay 

- Remaining packets are dropped as SLE transmission queue 
overflows 

• Initial observations: 

- SLE implementation utilized blocking communications 

- Based on observations and collaboration with 
Ingenicomm SLE developers 

- Supported byCCSDS SLE API Specifications and Standards 
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SLE Initial Results 


• Blocking Communications: 


- Maximum SLE PDU size is 64 kilobytes 


- Ka-Band Single Access Communication Link: 1.2 Gbps 


- Maximum expected round-trip-time 
delay across CONUS for the NASA 
Integrated Services Network (NISN)^ 

• 200 milliseconds 

- Maximum blocking throughput; 

• R=S/T 

• Approximately 2.62 Mbps at 200ms delay 


SLE 

Provider 

TCP 


TCP 

SLE 

User 









1) NASA Communication Service Office (CSO) Services Document (CSD) 
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SLE Initial Results 


• CCSDS SLE Performance Issues 

— CCSDS API Specifications for F-CLTU 

• Supports both blockingand non-blocking invocations for CLTU-TRANSFER-FRAME 

• Leaves it as an option forthe SLE implementation 

- Typically a non-issue 

• SLE is generally used for low data rate S-Band communication links 

• Data rates on the order of 50-100 kbps 

- For high bandwidth-delay product links 

• Significant reduction in achievablethroughput 


1. an implementation can always pass invocations for which a check hasfailedto the application 

2. an implementation can prevent queuing of invocations by withholdingan invocation until the previous 
invocation has been confirmed by the application. In that case, it can always generate the appropriate 
return when needed; or 

3. an implementation can decide to pass invocations to the application on a case by case basis 


Options for SLE Handlingof CLTU-TRANSFER-FRAME Return Message 

SLE F-CLTU API Specifications. Section 2.2.83 
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SLE Initial Results 


• Reaction to Initial Results: 

— Collaboration with SLE Vendor, Ingenicomm 
— Several weeks of narrowing down issue 
- Could not precisely determine issue: 

• No access to proprietary source code 

— Reported observations to SLE Vendor via NASA 
Technical Report 


17 


Improved Results 


Improved Ingenicomm CGS SLE Results 



Improved Results 


• Improved results: 

- Updated version of Ingenicomm CGS SLE Software 

- Based on direct collaboration with Ingenicomm developers 

- Issues with blocking communication resolved 

• Still reduced throughput at 1.2Gbps offered load 

- Packet error caused temporary TCP throttling 

- Brings down average throughput, no packet loss 

- Buffering at remote ground station required to maintain 
constant bitstream to satellite modem 
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Future SLE Work 


• Additional SLE Emulation Tests Required: 


- How do packet drops affect SLE data flow 


- Current observations: 

• TCP throttling 

• Temporary reduction 
in data throughput: 

- Future research: 

• Expected behavior of TCP 

• How can we work around 
this behavior 

- Additional buffering? 

- other protocols besides TCP? 


Data Rate and Delay Measurement for 1.4Gbps 
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Future Work in SCENIC Lab 


SLE is only one ground network protocol 

- Legacy protocols must be tested in the INA 
Network Environment to ensure compatibility 

- Future protocols can be tested to determine 
compatibility with space-based technologies 

Ingenicomm SLE is only one flavor of SLE 

- Compatibility testing with other SLE vendors 

- RT-Logic, VEGA, etc 



Future Work in SCENIC Lab 


• Full End-to-End Emulation Lab 

- Space-link emulation 

- Software Defined Radio (SDR) Development 

• Test proposed network protocols / waveforms 

• Fully integrated with ground network emulation testbed 
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Thank you! 


Questions? 



24 


